1. Field of Invention
The present invention relates generally to devices and methods for protecting computer software and in particular to devices and methods for protecting software by secure transmission and execution of encrypted software in a hardware key.
2. Description of Related Art
In the last decade, the use of computers in both the home and office have become widespread. The growing use of computers has resulted in extensive unauthorized use and copying of computer software, costing software developers substantial revenue. Although unauthorized copying of computer software is a violation of the law, the widespread availability of pirated software and enforcement difficulties have limited the effectiveness of this means of preventing software piracy.
Software developers and computer designers alike have sought technical solutions to attack the problem of software piracy. One solution uses an external device called a hardware key, or “dongle,” coupled to an input/output (I/O) port of the host computer. One such device is disclosed in U.S. Pat. No. 4,599,489, issued to Cargile on Jul. 8, 1986. The Cargile device executes a prescribed algorithm to produce a code which the computer receives and affords access to the software code if the code is correct. Another such device is disclosed in U.S. Pat. No. 4,446,519, issued to Thomas on May 1, 1984. This system also uses a hardware key coupled to the I/O port of a host computer. Software locks inserted into unprotected software programs cause the host computer to transmit a code to the hardware key. The hardware key processes the code to generate a response message. The software lock receives the response message, and compares the response to the expected response. If the received response is as expected, execution of the software is permitted to continue. If not, execution is terminated. A similar device is shown in U.S. Pat. No. 4,458,315, issued Jul. 3, 1984 to Uchenik.
Devices such as those disclosed in the Thomas and Uchenik references are not impervious to software piracy. Computer hackers can interrogate the dongle/host computer interface to determine query/response pairs, and could emulate the presence of a dongle with non-approved devices or software. In addition, computer hackers can obtain access to the protected software, find the software locks, and simply patch around them.
One solution to this problem is to perform selected software instructions in a secure hardware key, as disclosed in U.S. Pat. No. 4,634,807, issued Jan. 6, 1987 to Chorley et al. The Chorley device allows execution of portions of the protected software in a secure dongle coupled to a host computer I/O port. In the Chorley device, portions of the unprotected software, called software modules, are encrypted by a data encryption standard (DES) algorithm, producing a DES key and an encrypted module. The DES key is again encrypted, using a private/public encryption technique. The private key needed to decrypt the DES key is stored in the dongle. When the host computer requires execution of the software module, the encrypted software is transmitted to the secure dongle, and stored in its memory. The dongle processor decrypts the DES key using the private key, and uses the DES key to decrypt the software module. The software module is then stored in unprotected memory, where it can be operated on by a processor within the dongle. Access to the private and DES keys is controlled by a switch means which allows the dongle processor to access the memory in which the keys are stored only when the hardware key is initially activated. Upon activation, the private key is used to decrypt the DES key, and the DES key is used to decrypt the software module. Thereafter, the switching means prevents the dongle processor from accessing these keys.
While the Chorley device makes unauthorized access to the keys by the dongle processor difficult, it also prevents authorized access at any other time, and does not allow the memory in which the keys are stored to be used for other purposes. Also, the Chorley device is still not impervious to software piracy, because the unencrypted software module is eventually stored in the hardware key in an unprotected memory, where it can be accessed by the host computer. This may be prevented by enforcing encrypted and decrypted communications between the host computer and the dongle, such as disclosed in U.S. Pat. No. 4,596,898, issued on Jun. 24, 1986, to Permmaraju or U.S. Pat. No. 4,864,494, issued on Sep. 5, 1989, to Kobus, but this cannot be implemented with the Chorley device, because access to the keys is temporally limited.
Additional software protection devices are disclosed in U.S. Pat. No. 4,817,140, issued Mar. 28, 1989 to Chandra et al., and in U.S. Pat. No. 5,146,575, issued to Nolan et al. The Chandra and Nolan devices use a physically and logically secure co-processor to decrypt and execute software. Encryption and decryption keys and the algorithms using these keys are stored in the device in a secure non-volatile random access memory (RAM). Unlike Chorley, unauthorized access to plaintext software and the encryption/decryption keys is prevented by firmware-implemented functions rather than by a hardware switch. However, the Chandra and Nolan devices have practical limitations which limit their usefulness to prevent software piracy. First, the ultimate security of software protected by the Chandra and Nolan devices relies on the secrecy of a set of co-processor supervisor keys (CSKs) which must be pre-stored in all co-processors supplied by a given hardware vendor, and requires that the eventual software customer employ a use-once token cartridge to configure the co-processor to operate the protected software. The Chandra and Nolan devices also do not permit flexible access to other portions of the RAM which do not contain sensitive data. Because the Chandra device must be usable with a wide variety of software applications, it must employ an “open architecture,” and to prevent unauthorized access to sensitive information, is incapable of acquiring and transferring the right to execute the protected software. The Nolan device solves this problem by using a separate supervisor processor to implement a privilege structure and an open-architecture application processor to implement security functions. However, using two separate processors unnecessarily complicates the design and provides the potential software hacker with more opportunities to circumvent the software protection schemes employed in the device. The Nolan and Chandra devices are not immune from hacking by monitoring the co-processor/host interface, and using this data to emulate the hardware key.
Another problem with current software protection devices is that they are not backwards-compatible, and are not flexible enough to implement a wide variety of software protection algorithms within a single hardware key. For example a single host computer may store two separate software applications, the first protected with simple software locks, such as those described in the Thomas patent, and the second protected with encrypted computer/hardware key communications. Prior art software protection devices are incapable of supporting both of these software protection schemes, and two hardware keys would be required.